Hello @BlakeWilliams, @camertron, @joelhawksley, i tried to do what was discussed in #387 (comment), I would like to receive your opinions and see if there is a possibility of moving forward with this. Thanks.

Thanks for opening this PR and taking this on!

Similar to how we handled Slots V2, is there a way we could mark this functionality as experimental and have components opt-in to this feature? I think there's a lot of value in trying this functionality out in real applications and making modifications as necessary before making this a stable, long-term API.

@BlakeWilliams and I were chatting about this PR today and realized that there might be another option we could consider: private slots with templates but no sub-component, where the slot automatically accepts a single argument locals = {}.

For example, we might have:

# table_component.rb
class TableComponent < ViewComponent::Base
  renders_many :rows, private: true

  def initialize(items)
    items.each do |item|
      row({ title: item.title, author: item.author })
    end
  end
end

<!-- table_component.html.erb -->
<% rows.each do |row| %>
  <%= row %>
<% end %>

<!-- table_component/row.html.erb -->
<tr>
  <td><%= locals[:title] %></td>
  <td><%= locals[:author] %></td>
</tr>

I believe this would fulfill the desire for a private API and it would avoid allocating a new component for each row. What do y'all think?

@joelhawksley What should the rows array contain? An array of (html-safe) strings? Or some other intermediate object? While possibly not allocating a component, it would still store a (possibly) large array of something.

@fsateler yes, I think you'd have an array of HTML-safe strings.

Given the concerns about performance that are driving this work, I think it might be wise for us to implement a benchmark as part of this PR that compares the number of allocations with the new approach vs. an equivalent case with rendering a component for each row.

@joelhawksley I feel this proposal is not very railsy. In particular, the loop in the initializer feels like boilerplate. I don't really like the API.

Moreover, I think this proposal would require to have something like what this PR is proposing and on top adding the private slot API

@fsateler I think it would also be possible to use the plural slot setter if you didn't want to decompose items, like this:

# table_component.rb
class TableComponent < ViewComponent::Base
  renders_many :rows, private: true

  def initialize(items)
    rows(items)
  end
end

The difference between ☝🏻 and the proposal in this PR is that it remains inside of the existing Slots API, which I think would help reduce potential confusion around its introduction and use.

Has this moved along at all recently? I have a real need to be able to dynamically determine the template to render within a component, and this PR seems to enable that. Would be great to get something out, and I would be happy to help.

@joelmoss I don't think it's moved since my last comment from what I can tell. @jsolas @fsateler would you be OK with @joelmoss taking this on?

Not a problem on my side! If this helps things move forward, please go ahead!

Hi! I've been thinking about @joelhawksley 's proposal for a new API. I don't think it's going to work, not without a lot of refactoring:

1. with_<slotname> creates a SlotV2 object for each item in the collection.
2. This creation is eager, because at render time we iterate through @_set_slots[slot_name], which must have been prepopulated by with_<slotname>. This means the SlotV2 object creation is eagerly done.

This means we will create an intermediate array of intermediate objects, which is what we wanted to avoid.

Moreover, we still would need a lower-level api for actually rendering the template (which would be used by the slot interface). Please lets move forward with this as the lower-level API 🙏